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< ^ (57) Abstract: A method and apparatus to configure, monitor and manage network devices without regard for device type and/or 
- manufacturer is disclosed. One implementation of this embodiment includes a network manager unit disposed between the network 
administrator and the network devices. The network manager unit allows the administrator to holistically view, configure and manage 
an entire network without regard to device type and/or manufacturer. The administrator can implement this holistic approach with 
>^ Ihc use of a central repository for all configuration information and/or central posting location for all network events. 
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SYSTEM AND METHOD FOR CONFIGURATION, MANAGEMENT 
AND MONITORING OF NETWORK RESOURCES 

FIELD OF THE INVENTION 

5 The present invention relates generally to network systems. More particularly, 

but not by way of limitation, the present invention relates to systems and methods for 
configuration, management and monitoring of network resources such as routers, 
optical devices and the like. 

BACKGROUND OF THE INVENTION 

1 o With the ever-increasing reliance upon electronic data, businesses are 

becoming more and more reliant upon those networks responsible for distributing that 
data. Unfortunately, the rapid growth in the amount of data consumed by businesses 
has outpaced the development and growth of certain necessary network infrastructure 
components. One reason that the development and growth of the network 

1 5 infrastructure has lagged behind centers on the present difficulty in expanding, 
configuring, and reconfiguring existing networks. Even the most routine network 
expansions and reconfigurations, for example, require significant, highly technical, 
manual intervention by trained network administrators. Unfortunately, these highly 
trained network administrators are in extremely short supply. Thus, many needed 

20 network expansions and reconfigurations are delayed or even completely avoided 
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because of the inability to find the needed administrators to perform the required 
laborious, technical tasks. 

The present difficulty in configuring and reconfiguring networks is best 
illustrated by an example directed toward installing a single new router on an existing 
5 network. To install a new router (such as router 100 or 105 in FIGURE 1), an 

administrator 110 first would need to choose a particular router with the best attributes 
for the network. The basic configuration of the new router generally will be defined by 
its manufacturer and its model. Although it would seem that the router should be 
chosen based upon its attributes, administrators 110 often choose a router based upon 
10 the identity of its manufacturer and the administrators' ability to configure devices from 
that manufacturer. Administrators 1 1 0, for example, may only know how to configure 
and operate devices manufactured by Cisco Systems, Inc. and may overlook equal or 
even superior devices from other manufacturers merely because they cannot configure 
them. 

■* 

1 5 After the administrator 1 1 0 has chosen the desired router (router 1 05, for 

example), the administrator 1 10 generally will order the router 105 from the 
manufacturer and have it shipped, not necessarily to the installation site, but rather to 
the administrator's site where a basic configuration can be installed. The administrator 
110 then ships the router 1 05 to the installation site where it can be physically installed. 

20 After the router 105 has been physically installed, the administrator 1 10 typically is 
manually notified, e.g., by telephone, that the router 105 is connected to the network. 
The administrator must then create the device-specific commands required to fully 
configure the router 105 and transfer those commands to the router's memory 115. 
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After the administrator 1 10 verifies that the device-specific commands were installed 
correctly, the router 1 05 can be brought online. 

Obviously, the steps required for an administrator to configure a single router 
are quite cumbersome and require significant technical skill. The problem, however, is 

5 even more severe when the administrator desires to simultaneously configure or 

reconfigure several network devices. First, the administrator, for example, would need 
to manually identify the network devices that need to be configured or reconfigured. 
For example, if the administrator desired to turn up service between two points, the 
administrator would need to identify the routers along the path between the two points. 

1 0 The administrator would then need to verify that the policies and rules established for 
the network permit the contemplated reconfiguration for those devices. Assuming that 
the reconfiguration is within the network's policies and rules, the administrator would 
need to create the device-specific code required to reconfigure each of the identified 
devices. In many instances, the same device-specific code cannot be used on all of the 

1 5 devices. For example, the device-specific commands required to reconfigure a Cisco™ 
router differ significantly from the device-specific commands required to reconfigure a 
Juniper™ router. Thus, if the identified network devices include both Cisco™ and 
Juniper™ routers, the administrator would be required to create different versions of - 
the device-specific commands, thereby significantly increasing the chance for error in 

20 the reconfiguration process. 

Once the device-specific commands have been created for each of the identified 
network devices, the commands must be manually transmitted to each device. That is, 
a connection, e.g., a telnet connection, must be established to each device and the 
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particular commands transferred thereto. After each device has received its commands, 
the network administrator must manually reconnect to each device and verify that the 
device received the proper commands and that it is operating properly. 

Although some tools have been developed to help administrators perform 
5 certain ones of the laborious tasks of network management, these tools are extremely 
limited in their application. For example, CiscoWorks™ is a group of unrelated tools 
that can aid administrators in some enterprise level tasks. CiscoWorks™ and similar 
tools provide singularly focused, unrelated topis to perform activities such as quality of 
service (QOS) provisioning and network policy management. These tools do not 
10 provide a way to interrelate the various happenings in a network. In essence, these 
present network tools lack a holistic approach to network administration. 

Moreover, tools like CiscoWorks™ are generally dedicated to the management 
of one type of network device, e.g., router or optical device, and one brand of network 
. device. For example, CiscoWorks™ does not help an administrator configure a 
15 Juniper™ router, and it does not help an administrator configure optical devices. Thus, 
if the network has both Cisco™ and Juniper™ devices, multiple, unrelated tools must 
be utilized to perform basic network management tasks. Unfortunately, because these 
multiple, unrelated tools are so difficult to manage, network administrators are prone to 
select routers based upon manufacturer identity rather than upon device features. 

20 In addition to several other drawbacks, these singularly focused network tools 

result in substandard fault detection and recovery. For example, in present systems, 
once a configuration is changed, there is no easy way to "back out" of that 
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configuration if a problem arises. Presently, if a new configuration for a target device 
fails, the network administrator would be forced to recreate the device-specific 
commands of the target device's previous configuration, manually connect to the 
device and then transmit the recreated device-specific commands to the device. As can 
5 be appreciated, this process can be extremely time consuming and error prone. 

The lack of a comprehensive, holistic tool to manage network resources has led 
to slowed expansion and the under utilization of existing networks. As skilled 
administrators become more scarce and as networks grow larger and more complicated, 
the problems surrounding network management could reach crisis proportions. 
10 Accordingly, an integrated network administration tool is needed. In particular, a 
system and method are needed to efficiently configure, monitor and manage network 
devices without regard for device type and/or manufacturer. 

SUMMARY OF THE INVENTION 

To remedy the above described and other deficiencies of the current 
15 technology, a system and method for the configuration and monitoring of network 
devices has been developed. In one embodiment, the present invention provides a 
system and method to configure, monitor and/or manage network devices without 
regard to device type and/or manufacturer identity. One implementation of this 
embodiment includes a network manager unit disposed between the network 
20 administrator and the network devices. The network manager unit allows the 

administrator to holistically view, configure and manage an entire network. That is, the 
administrator can view, configure and manage, for example, both optical devices and/or 

5 
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routers without regard to manufacturer identity or specific model. The administrator 
can implement this holistic approach with the use of a central repository for all 
configuration information and/or a central posting location for all network events. 

In one embodiment, for example, an administrator can configure a new 
5 device or reconfigure an existing clevice by logging into the network manager unit and 
selecting a particular network device to configure. The network manager unit can then 
retrieve a configuration record unique to the selected network device from the common 
repository and provide that record to the administrator. After receiving the record, the 
administrator can change fields therein without regard for manufacturer identity of the 

1 0 network device. Next, the network manager unit can automatically verify that the 
requested changes to the configuration record comply with the policies and rules 
established for the network, and assuming that the changes do not violate any of the 
policies or rules, the network manager unit can update arid store the modified 
configuration record in the central repository. A copy of the old configuration record 

1 5 can be kept in the central repository for fault recovery, modeling and other purposes. 

Once the configuration record has been changed, network manager unit can 
use the fields of the modified configuration record to generate the actual device-specific 
commands needed to configure the selected network device. For example, the fields in 
the configuration record can be used to populate variable fields in a device-specific 
20 code template. In such an embodiment, the administrator is not requiried to know or 
create the actual device-specific commands that are required to configure the selected 
network device. Instead, the administrator only needs to know the general objective 
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such as "enable router." The network manager unit will transform this general 
objective into the actual device-specific commands. 

After the network manager unit has created the device-specific commands to 
match the altered configuration record, these commands are automatically pushed to the 
5 selected network device and stored in memory therein. A copy of those commands is 
also stored in association with the configuration record. Finally, after the new device- 
specific commands have been pushed to the selected network device, the network 
manager unit can verify the proper installation and operation of the new configuration 
information. 

I o in essence, one embodiment of the present invention allows a configuration 

record to be created and/or modified for each network device regardless, of the device's 
type, manufacturer or model. Each of the configuration records can be stored in a . 
central repository for simplified access, retrieval and editing. Thus, to change the 
configuration for any network device, the network manager unit need only retrieve the 

15 altered configuration record from the central repository, generate the device-specific 
commands based upon that configuration record and push those generated device- 
specific commands to the target network device. 

In another innovative aspect, the present invention enables automatically 
responses to network events. For example, network devices can be configured to post 
20 messages to a central posting location at the network manager unit. The network 
manager unit can read these posted network events from the central posting location 
and determine a proper response based upon predefined rules and policies. The 
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network manager unit can then automatically implement the response. For example, if 
a particular router becomes congested, that router can post a message to the central 
posting location. The network manager unit can then read that message and determine 
the appropriate response for the congested router. The policy could indicate, for 
5 example, that the router configuration should be changed to enable congestion handling 
features. The network manager unit, in this scenario, could automatically reconfigure 
the router to enable those congestion-handling features. 

As can be appreciated by those skilled in the art, the present invention addresses 
the significant shortfalls in present network technology. In particular, the present 
1 0 invention, provides a holistically way to configure, manage and view an entire network 
system. These and other advantages of the present invention are described more fully 
herein. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Various objects and advantages and a more complete understanding of the 
1 5 present invention are apparent and more readily appreciated by reference to the 

following Detailed Description and to the appended claims when taken in conjunction 
with the accompanying Drawings wherein: 

FIGURE 1 illustrates a present system for configuring network routers; 

. FIGURE 2 illustrates a system for configuring network devices in accordance 
20 with the principles of the present invention; 
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FIGURE 3 illustrates in more detail the network manager unit shown in 

FIGURE 2; r " 

FIGURE 4 illustrates in more detail the directory element shown in FIGURE 3; 

FIGURE 5 illustrates a configuration record for a typical network device in 
5 accord ance with the present invention; 

FIGURE 6 illustrates in more detail the event bus shown in FIGURE 3; and 

FIGURE 7 is a flow chart of a method for configuring a network device in 
accordance with the present invention. 

DETAILED DESCRIPTION 

10 Although the present invention is open to various modifications and alternative 

constructions, a preferred exemplary embodiment that is shown in the drawings is 
described herein in detail. It is to be understood, however, that there is no intention to 
limit the invention to the particular forms disclosed. One skilled in the art can 
recognize that there are numerous modifications, equivalents and alternative 

1 5 constructions that fall within the spirit and scope of the invention as expressed in the 
claims. 

Refeiring now to FIGURE 2, there is illustrated a system 120 for configuring 
network devices 100, 105, 125, 1 30 (collectively 135) in accordance with the principles 
of the present invention. This embodiment includes a network manager unit 1 40 
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disposed between the administrator 110 and the network devices 135, which can 
include routers, optical devices, etc. The network manager unit 140 also is connected 
to remote storage 145 (connected by network 150) and a network manager support 155. 

To alter the configuration of a network device 135 or to add a network device to 
an existing network, the administrator 1 10 can access the network manager unit 140, 
search for and retrieve the configuration record corresponding to a target network 
device, and through a series of interactive, wizard-like screens, change the 
configuration record for the target network device. This altered configuration record is 
stored in a central repository in the network manager unit 140 and can be checked 
against network policies accessible by the network manager unit 140. Next, the 
network manager unit 1 40 can generate device-specific commands from the new 
configuration record and push those device-specific commands to the target network 
device or have the target network device pull the commands^ Finally, the network 
manager unit 140 can verify that the new configuration was installed correctly at the 
target network device. 

To generate the necessary device-specific commands, the network manager unit 
140 may access the remote storage device 145 that can contain the various templates 
needed to generate device-specific commands for different types, brands and/or models 
of network devices. Each of these templates can contain variable fields corresponding 
20 to either information stored in the configuration records or information input directly by 
the administrator. The network manager unit 140 generates the device-specific 
commands by retrieving the appropriate template and filling in the variable fields with 
the data from the configuration records and/or data input directly by the administrator 



10 



10 



r c 

WO 02/47332 .PCTAJS01/45669 

i 1 0. Once generated, these device-specific commands can be stored in the 
configuration record and/or they can be stored in the remote storage device 145 with an 
appropriate pointer stored in the configuration record. 

As can be appreciated by those skilled in the art, the network manager unit 140 
5 can be implemented on virtually any hardware system. Good results, however, have 
been achieved using components running the Red Hat™ LINUX Operating System and 
the Sun Solaris™ UNIX Operating System. In embodiments running either of these 
operating systems, the network manager unit 140 is configured to utilize the common 
services provided by that particular operating system. 

Referring now to FIGURE 3, there is illustrated in more detail the network 
manager unit 140 shown in FIGURE 2. This embodiment of the network manager unit 
140 includes six basic modules: an interface 160, a directory 165, a policy manager 
170, an event bus 175, a health manager 1 80 and an action manager 1 85. The 
illustrated connections between the various components are exemplary only. The 
components can be connected in a variety of ways without changing the basic operation 
of the system. Although the division of the network manager unit 140 into the six 
components is the presently preferred embodiment, the functions of these components 
could be subdivided, grouped together, deleted and/or supplemented so that more or 
less components can be utilized in any particular implementation. Thus, the network 
manager unit 140 can be embodied in several forms other than the one illustrated in 
FIGURE 3. 
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Referring first to the interface module 160, it is designed to exchange data with 
the administrator 1 10 (shown in FIGURE 2) and, in some embodiments, with the 
network devices 135 (also shown in FIGURE 2). Although the interface 1 60 could 
implement virtually any type of interface, good results have been achieved using a 
5 graphical, web interface. Other interfaces can be based upon wireless protocols such as 
WAP (wireless application protocol). 

The second component of the network manager unit 1 40 is the event bus 1 75. 
The event bus 175 includes a central posting location for receiving messages relating to 
network events. For example, when a configuration for a network device 135 is to be 

10 changed, an appropriate message can be published (or otherwise made available) to the 
event bus 175. Similarly, if a network condition such as an error occurs, an appropriate 
message can be published to the event bus 175. Notably, any message published to the 
event bus 175 can also be sent to the administrator 1 10 by way of the interface 160. 
The administrator 1 10, however, does not necessarily need to respond to a received 

1 5 message for the event to be addressed by the network manager unit 140. 

To determine the proper response for a message posted to the event bus 175, the 
received message can be compared against the policies stored in the policy manager 
170, which is a repository for the business and network policies. and rules used to 
manage the network. By using these rules and policies, an administrator 1 10 (shown in 
20 FIGURE 2) can define a response for any event published to the event bus 175. The 
defined response can be virtually anything including reconfiguring a network device, 
shutting down a network device and notifying an administrator. 
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In operation, the policy manager 1 70 can read a message posted to the event bus " 
175. Alternatively, the event bus 175 can automatically push the message to the policy 
manager 170. Either way, however, the policy manager 170 uses the message to access 
the policy records that can be stored, for example, in a look-up table and to correlate the 
5 message to the appropriate response. Once the policy manager 1 70 has determined the 
appropriate response, that response is published to the event bus 175 as a work order 
that can be read by the action manager 1 85 and subsequently executed. That is, the 
action manager 185 can read the work order from the event bus 175 and perform the 
necessary tasks to complete that work order. In other embodiments, the work order can 
1 0 be sent directly to the action manager 185. For example, assume that the action 

manager 1 85 reads a work order from the event bus 1 75 that indicates two routers - one 
a Cisco™ router and one a Juniper™ router - need to be enabled. The action manager 
1 85 can locate each of these routers and determine the device-specific code needed to 
enable them. The code required to enable the Cisco™ router, for example, might be 
1 5 "enable_router" and the code required to enable the Juniper™ router might be 

"router_enable." Because the action manager 185 determines the appropriate device- 
specific code, however, the administrator 1 1 0 (shown in FIGURE 2) only needs to 
generically indicate that both devices are to be enabled. The administrator 1 10 does not 
need to know the actual device-specific code required by each router. 

20 In other embodiments, the action manager 1 85 can verify that the administrator 

1 1 0 (shown in FIGURE 2) has authority to make changes to network devices without 
authorization from additional parties. If additional authorization is required, the action 
manager 1 85 can post an appropriate message to the event bus 175. 

.13 
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Still referring to FIGURE 3, the directory 1 65 of the network manager unit 140 
- . includes a central repository for storing the configuration records of each of the 
network devices connected to the network manager unit 140. For example, the 
directory 165 could store a separate configuration record for each of network devices 
5 1 00, 105, 125 and 130 shown in FIGURE 2. In certain embodiments, several 

interconnected directories may be utilized, and in such systems, each directory can 
store a certain subset of the configuration records or a complete copy of all of the 
configuration records. Generally, such embodiments would employ multiple linked 
network manager units 140, and in the embodiment where complete copies of the 
10 configuration records are stored in different directories, synchronization techniques can 
be used to guarantee data integrity. 

The configuration records stored in the directory 165 are searchable by way of 
the interface 160. That is, the administrator 1 10 or a component within the network 
manager 140 (shown in FIGURE 2) can initiate a search through the interface 160 and 

1 5 the results of that search can be made available to the administrator 1 1 0 through the 
interface 160. Moreover, the configuration records can be searched in any of a variety 
of ways. For example, the configuration records can be searched according to 
equipment type (e.g., routers, optical devices, etc.), device type (edge router, core 
router, etc.), device location, device manufacturer, device model, device name, 

20 operational status, etc. The directory 165 can be used to enable directory-based 
networking. 

Referring now to the health manager 1 80, it can be configured to monitor the 
overall health of the network and/or the health of individual network devices 135 

14 
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(shown in FIGURE 2) within the network. The health manager 180 can operate in an - 
active mode and/or a passive mode. In the active mode, the health manager actively 
polls at least some of the network devices 135 about their status, utilization, congestion, 
etc. In the passive mode, the various network devices 135 automatically report to the 

5 health manager 1 80. In either embodiment, however, the health manager 180 can 

collect individual device information and model overall network health. Additionally, 
the health manager 180 can publish messages regarding network device problems, 
projected network device problems, network problems, and/or projected network 
problems. The policy manager 170 can then determine the appropriate course of action 

10 to take for the particular message and the action manager 1 85 can implement that 
response. 

In further embodiments, the health manager can monitor the health of the 
network manager components. For example, the health manager can monitor the 
operation of the event bus, the action manager and/or the directory. Moreover, the 
15 health manager can monitor the flow of data between the various components of the 
network manager. 

Referring now to FIGURE 4, there is illustrated in more detail the directory 165 
shown in FIGURE 3. This embodiment of the directory 1 65 consists of four 
interconnected modules: configuration storage 187, configuration comparator 190, 
20 configuration reader 195 and interface 200. The directory 165, however, does not need 
all of the modules to function in accordance with the principles of the present 
invention. 
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The configuration reader module 195 of the directory 165 is designed to initiate 
communication with (or directly communicate with) a target network device and 
retrieve that device's actual configuration. For example, the configuration reader can 
retrieve the actual configuration from the memory 1 15 of router 105 (shown in 
5 FIGURE 2). This retrieved actual configuration can then be passed to the configuration 
comparator 190. The configuration reader 195 can also retrieve the intended 
configuration of the target device from the configuration storage 1 87 and pass that 
intended configuration to the configuration comparator 190. The configuration 
comparator 190 can then compare the actual configuration and the intended 
1 0 configuration and present the differences to the administrator 1 1 0 (shown in FIGURE 
2). In one embodiment^ the differences in the configurations are not only presented 
literally, but also in a natural language summary form. Once the differences have been 
identified, they can be used to identify a failed configuration installation and/or to aid 
the administrator in creating the proper configuration for a device. 

15 As previously discussed, the configuration storage 1 87 is designed to store 

configuration records corresponding to network devices such as network devices 135 
shown in FIGURE 2. In one embodiment the configuration storage 187 is designed not 
only to store the present configuration record for a network device, but also to store 
previous configuration records for that device. By storing these previous 

20 configurations, fault recovery and correction are vastly improved over present systems 
because prior, successful configurations can be quickly retrieved and used to replace 
new, faulty configurations. For example, a prior configuration of a previously known 
good state can be retrieved and installed on the associated network device. This prior 

16 
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configuration could be days old or even weeks old. Prior configuration records can be 
distinguished by version numbers and/or a time stamp. Additionally, each 
configuration record can include a searchable summary that includes notes on the 
configuration and why that configuration was modified. 

5 Referring now to FIGURE 5, there is illustrated a configuration record 205 for a 

typical network device. This configuration record 205 is divided into four portions:* a 
common information model ("CIM") data portion 210, a vendor data portion 215, 
proprietary data portion 220 and a data pointer 225. The CIM data portion 210 contains 
data relating to the physical attributes of a particular network device such as name, 

1 0 device type, number of interfaces, capacity, etc. The CIM data items are defined in the 
CIM Specification v2.2 and the CIM Schema v2. 4, both of which are well known in the 
art and incorporated herein by reference. 

The vendor data portion 215 of the configuration record contains standard 
vendor-specific data regarding the particular network device. For example, the vendor 
1 5 data portion 2 1 5 could indicate which version of an operating system that the network 
device is running or which features of the device are enabled. Generally, the data in the 
vendor data portion 215 is specific to each manufacturer and even to each model of 
network device. 

The proprietary data portion 220 of the configuration record can contain data 
20 used by the network manager unit in configuring and managing the network devices. 
In one embodiment, for example, the proprietary data portion 220 includes a pointer to 
an address at which a core dump for a network device is stored; .That is, if a router 
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initiates a core dump, the location of that core dump could be recorded in the 
proprietary data portion 220 of the configuration record for that router. In other 
embodiments, the proprietary data portion 220 can store version numbers, time stamps, 
health records for a particular configuration, configuration summary data, configuration 
5 notes, etc. 

The pointer portion 225 of the configuration record 205 can be used to point to 
a storage location where the actual device-specific commands for the associated 
network device are stored. Similarly, the pointer 225 could be configured to point to a 
storage location for a device-specific template for configuring a newly installed 
10 network device. In other embodiments, the pointer portion 225 of the configuration 
record can be supplemented or replaced with a storage location for actual device- 
specific code. 

Referring now to FIGURE 6, there is illustrated in more detail the event bus 175 
shown in FIGURE 3. As previously described, the event bus 175 is a posting location 
15 for messages relating to network events. Network devices as well as the other 

components of the network manager unit 140 (shown in FIGURE 2) can address and 
post events to the event bus 175. 

The particular embodiment of the event bus 1 75 shown in FIGURE 6 is 
comprised of four basic modules: an interface 230, a status storage 235, an event queue 
20 240, and an event queue manager 245. In operation, a message indicating the 

occurrence of a network event is posted to the event queue 240 by way of the interface 
230. The messages stored jat the event queue 240 are then made available to the policy 
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manager 1 70 (shown in FIGURE 3), so that a proper response can be determined. If 
the posted message is a work order from the policy manager 170, the work order is 
made available to the action manager 185 (shown in FIGURE 3) for subsequent 
implementation. 

5 In one embodiment of the event bus 175, an event message is stored in status 

storage 235 along with a status field and an age field. Thus, for any message posted to 
the event bus 175, its status and age can be continuously monitored. (The event bus 
can also get messages from client devices.) For example, status storage 235 could 
indicate that the status for a particular event is pending in the action manager 185 

10 (shown in FIGURE 3), awaiting proper authorization, completed, stalled, etc. As the 
status changes from one status to another, appropriate messages can be generated and 
posted at the event queue 240. For example, if the status of an event changes from 
pending to stalled, an appropriate message can be posted to the event queue 240 so that 
the policy manager 170 can determine how to respond. Similarly, if the age field in the 

1 5 status storage 235 indicates that a particular network event has not been addressed 
within a predetermined amount of time, that event can be requeued, deleted from the 
event queue 240, or a new event notification indicating the delay can be generated and 
placed on the event queue 240. 

Referring now to FIGURE 7, there is a flow chart of one method for 
20 configuring or reconfiguring a network device in accordance with the principles of the 
present invention. In this embodiment, the administrator 110 (shown in FIGURE 2) 
initially logs in to the network manager unit 140 (Step 250). Through a series of a 
graphical interfaces, the administrator 1 10 can select a network device that needs to be 
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configured or reconfigured. The configuration record associated with the selected 
device can then be retrieved from the directory 1 65 (shown in FIGURE 3) and 
presented to the administrator (Step 255). If no configuration record is available for a 
selected device, the administrator 110 will be guided through a series of steps to build 
5 the configuration for that device. Otherwise, the administrator 110 can change 

parameters within the configuration record of the selected device and save those altered 
configuration records within the directory 165 (Step 260). Notably, even though the 
configuration record for the selected network device has been changed, the actual 
configuration of the device has not been changed. Before the configuration of the 

10 device can be changed, an event message indicating that a configuration record has 
been altered should be published to the event bus 1 75 (shown in FIGURE 3) (Step 
265). The policy manager .170 (shown in FIGURE 3) then receives the event message, 
either by reading it from the event bus 1 75 or by receiving it from the event bus 1 75, 
and determines if the configuration change is authorized (Step 270). If the 

15 configuration change is within the network rules and the administrator 110 (shown in 
FIGURE 2) is authorized to make the change, a work order is published to the event 
bus (Step 280). The action manager 185 (shown in FIGURE 3) can then read the work 
order from the event bus 1 75 and carry out the necessary steps to implement the work 
order (Step 280). 

20 In one embodiment, the action manager 1 85 (shown in FIGURE 3) carries out 

the work order by locating the target network device, retrieving the appropriate 
configuration record from the directory 1 65 (shown in FIGURE 3), generating the ( 
device-specific code corresponding to the altered configuration (Step 290), and pushing ! 
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the device-specific code to the target network device (Step 295). The action manger 
1 85 can also store the device-specific code in a remote storage device, such as remote 
storage device 145 shown in FIGURE 2, and a pointer to the remote storage device can 
be recorded in the configuration record. Finally, the action manager 1 85 can verify that 
5 the device-specific code was properly transferred to the selected network device and 
that the network device is behaving accordingly (Step 300). Assuming that the device- 
specific codes were installed correctly and that the network device is operating 
properly, a completion message is published to the event bus 175 (shown in FIGURE 
3) (Step 305), 

10 In conclusion, the present system provides, among other things, a method and 

apparatus to configure* monitor and manage network devices without regard for device 
type and/or manufacturer. Those skilled in the art, however, can readily recognize that 
numerous variations and substitutions may be made in the invention, its use and its 
configuration to achieve substantially the same results as achieved by the embodiments 

1 5 described herein. Accordingly, there is no intention to limit the invention to the 
disclosed exemplary forms. Many variations, modifications and. alternative 
constructions fall within the scope and spirit of the disclosed invention as expressed in 
the claims. 
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WHAT IS CLAIMED IS : ^ V 

1 . A computerized method for configuring a network device, the method 
* comprising the steps of: 

retrieving a configuration record from a common repository of configuration 
5 records, the retrieved configuration record being associated with the network device; 
modifying the retrieved configuration record; 
storing the modified configuration record in the common repository; 
generating at least one device-specific command corresponding to the modified 
configuration record; and 
1 0 transferring the generated first device-specific command to the network device. 

2. 1 The computerized method of claim 1, further comprising the step of: 
searching the common repository for the configuration record; 

wherein the configuration record is one of a plurality of configuration records 
stored in the common repository. 
15 3. The computerized method of claim 1 , further comprising the step of: 

publishing a message to an event bus; 

wherein the published message indicates that the retrieved configuration record 
has been modified. 

4. The computerized method of claim 1, further comprising the step of: 
20 verifying that the modified configuration record complies with a network 

policy. 
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- 7 - 5. : The computerized method of claim 4, fbrther comprising the step of: 

publishing a work order to an. event bus in response to verifying that the 
modified configuration record complies with a network policy. 

6.. The method of claim 1, further comprising the step of: 
5 verifying the successful completion of the step of transferring the generated first 

device-specific command to the network device. 

7. The method of claim 1, further comprising the step of: 
receiving an event notification at an event bus, the event notification being 

generated by the network device; 
1 0 wherein the step of retrieving the configuration record is initiated in response to 

the receiving of the event notification at the event bus. 

8. The method of claim 1, wherein the step of generating the at least one 
device-specific command comprises the steps of: 

retrieving a device-specific command template, wherein the device-specific 
1 5 command template comprises at least one variable field; and 

populating the at least one variable field with data included in the modified 

configuration record. 

9. The method of claim 8, wherein the retrieved configuration record 
indicates that the network device is from a particular manufacturer, and wherein the 

20 retrieved device-specific command template is unique to the particular manufacturer. 

10. The method of claim 8, wherein the retrieved configuration record 
indicates that the network device is a particular device type and wherein the retrieved 
device-specific command template is unique to the particular device type. 
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1 1 . The method of claim 1 , wherein the step of retrieving the configuration 
record comprises the step of: 

retrieving the configuration record from a distributed common repository. 

12. A system for configuring a network including a plurality of network 
5 devices, the system comprising: 

an event posting component configured to receive a network event posting 
related to a first of the plurality of network devices; and 

an action manager in communication with the event posting component, the 
action manager configured to receive the network event posting and to configure the 
10 first of the plurality of network devices in accordance with the network event posting. 

13. The system of claim 12, further comprising: 

a configuration storage module in communication with the event posting 
component, the configuration storage module configured to store at least one 
configuration record for each of the plurality of network devices; 
1 5 wherein the action manager is configured to configure the first of the plurality 

of network devices by utilizing a configuration record corresponding to the first of the 
plurality network device. 

14. The system of claim 13, wherein the configuration storage module 
comprises a distributed storage arrangement. 

20 15. The system of claim 12, further comprising: 

a policy manager in communication with the event posting component. 

16. The system of claim 12, further comprising: 

a health manager in communication with the event posting component; 
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wherein the health manager is configured to monitor the health of at least one of 
the plurality of network devices and to report the health of the at least one of the 
plurality of network devices to the event posting component. 

17 v The system of claim 12, wherein the event posting component 
5 comprises: 

a central posting location. 

1 8. The system of claim 1 2, wherein the event posting component 
comprises: 

a distributed posting location. 
10 19. The system of claim 12, further comprising: 

a device-specific template storage module in communication with the action 
manager, the device-specific template storage module configured to store a plurality of 
device-specific command templates. 

20. The system of claim 1 9, wherein the action manager is configured to 
1 5 read a first of the plurality of device-specific templates from the device-specific 
template storage module and generate a device-specific command using the read 
device-specific template; 

wherein the generated device-specific command is enabled to configure the first 
of the plurality of network devices in accordance with the network posting. 
20 21. A system for configuring a network including a plurality of network 

devices, the system comprising: 

a configuration storage module configured to store at least one configuration 
record for each of the plurality of network devices; and 
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an action manager in communication with the configuration storage module, the 
action manager configured to receive an indication that a first of the configuration 
records has been altered, and the action manager being further configured to generate a 
device-specific command for a network device included in the plurality of network 
5 devices, wherein the network device corresponds to the first of the configuration 
records. 

22. The system of claim 21, further comprising: 
an event posting component configured to provide to the action manager the 
indication that the first of the configuration records has been altered. 
10 23. The system of claim 2 1 , further comprising: 

a policy manager in communication with the event posting component. 

24. The system of claim 21, further comprising: 

-a device-specific template storage module in communication with the action 
manager, the device-specific template storage module configured to store a plurality of 
15 device-specific command templates; 

wherein at least a first of the plurality of device-specific command templates is 
usable by the action manager to generate the device-specific command for the network 
device. 

25. A system for configuring a network device, the system comprising: 
20 at least a first processing element configured to execute instructions; 

at least a first memory device electronically coupled with the at least a first 
processing element; and 
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a plurality of instructions stored on the memory device, the plurality of 
instructions configured to cause the at least a first processing element to perform the 
steps of: 

retrieving a configuration record from a common repository of 
5 configuration records, the retrieved configuration record being associated with the 
network device; 

modifying the retrieved configuration record; 

storing the modified configuration record in the common repository; 

generating at least a first device-specific command corresponding to the 
1 0 modified configuration record; and 

transferring the generated first device-specific command to the network 

device. 

26. The system of claim 25, wherein the plurality of instructions are further 
configured to cause the at least a first processor to perform the step of: 

1 5 searching the common repository for the configuration record; 

wherein the configuration record is one of a plurality of configuration records 
stored in the common repository. 

27. The system of claim 25, wherein the plurality of instructions are further 
configured to cause the at least a first processor to perform the step of: 

20 publishing a message to an event bus; 

wherein the published message indicates that the retrieved configuration record 
has been modified. 

28. The system of claim 25, wherein the plurality of instructions are further 
configured to cause the at least a first processor to perform the step of: 
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verifying that the modified configuration record complies with a network 
policyv' 

29. The system of claim 28, wherein the plurality of instructions are further 
configured to cause the at least a first processor to perform the step of: 

5 publishing a work order to an event bus in response to verifying that the 

modified configuration record complies with a network policy. 

30. The system of claim 28, wherein the plurality of instructions are further 
configured to cause the at least a first processor to perform the step of: 

verifying the successful completion of the step of transferring the generated first 
1 0 device-specific command to the network device. 

3 1 . The system of claim 25, wherein the plurality of instructions are further 
configured to cause the at least a first processor to perform the step of: 

receiving an event notification at an event bus, the event notification being 
generated by the network device; 
15 wherein the step of retrieving the configuration record is initiated in response to 

the receiving of the event notification at the event bus. 

32. The system of claim 25, wherein the plurality of instructions are 
configured to cause the at least a first processor to generate the at least a first device- 
specific command by: 

20 J retrieving a device-specific command template, wherein the device-specific 

command template comprises at least one variable field; and 

populating the at least one variable field with data included in the modified 
configuration record. 
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33 . The system of claim 32, wherein the retrieved configuration record 
indicates that the network device is from a particular manufacturer and wherein the 
retrieved device-specific command template is unique to the particular manufacturer. 

34. The system of claim 32, wherein the retrieved configuration record 

5 indicates that the network device is a particular device type and wherein the retrieved 
device-specific command template is unique to the particular device type. 

35. The system of claim 25, wherein the plurality of instructions are 
configured to cause the at least a first processor to perform the step of retrieving the 
configuration record by: 

10 retrieving the configuration record from a distributed common repository. 

36. A system for configuring a network device, the system comprising: 
means for retrieving a configuration record from a common repository of 

configuration records, the retrieved configuration record associated with the network 
device; 

1 5 means for modifying the retrieved configuration record; and 

means for storing the modified configuration record in the common repository. 

37. The system of claim 36, further comprising: 

means for generating at least a first device-specific command corresponding to 
the modified configuration record; and 
20 means for transferring the generated first device-specific command to the 

network device. 
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